Many databases, including relational and post-relational databases, store data structured in records (sometimes called rows) in tables with a fixed or varying number of columns. As used herein, a post-relational database, such as a NoSQL database, refers to data that are modeled by other means than the tabular relations used in relational databases; such other means may be used in place of tabular relations or alongside with these. Post-relational databases have been in commercial use at least since the 1990s and may perform better in large-scale data analysis and other so-called big data applications than relational databases.
A record in this sense may be in conformity with a definition that requires values to be assigned for some but not all of its columns. Further, a document or an object may play the role of a record in a document-based or object-based database, respectively. Relational databases in particular store data structured in rows (tuples) in tables (relations) of a number of columns (attributes) that may be set when a table is initiated. An intersection of a row and a column is referred to as a cell. A database need not comprise more than one row, table or column, respectively. Data are read and/or modified by means of queries to the database, which are composed by a human user or generated by an application or process that executes on a computer storing the database or is communicatively connected thereto. Queries may be conformal to a query language, such as SQL, HiveQL, SPARQL, DMX or OQL, for which syntactic and other rules are defined.
Access to reading or modifying the data may be restricted, in which case the database must be protected with an AC policy that must be enforced. In many cases, the conditions for permitted access may:                be fine grained, that is, the unit which must be protected in the database must be small, typically an individual cell. This means that the access conditions for each cell must be enforced individually;        depend on data content of the database. For instance, to be permitted to access a cell with salary data, the conditions would depend on the values of other columns in the row being accessed;        depend on external information related to the subject accessing the database, other data related to the data in the database or other contextual information.Currently, the access restrictions of these fine-grained and data-dependent types are typically encoded by hand into the applications that generate database queries, so that non-permitted rows are filtered out. This is undesirable because the AC policy becomes embedded in the application, which results in a number of drawbacks:        Changing the access control policy requires a change in the behavior of the application that generates queries, which may be difficult to achieve unless source code of the application is available.        An application without proprietary access control cannot be protected at all unless it is modified, which may be difficult to achieve if source code of the application is not available.        The access control policy is not clearly visible as such; rather it is distributed in the database queries and mixed with business-logic aspects, making it difficult to validate that the policy is correct or to understand which policy is being applied.        
Existing approaches to apply an access control policy outside the application's SQL queries are restricted in their capabilities to express fine-grained conditions, conditions depending on external data and the richness of the conditional expressions themselves.
There currently exist general-purpose AC languages that have the richness to express fine-grained conditions and conditions which depend on external data. As explained in the note “The Relationship Between XACML and P3P Privacy Policies” by A. Anderson, Sun Microsystems, Inc. (2004), a first, low-level type of policy languages (e.g., Extensible Access Control Markup Language, XACML) is primarily aimed at expressing access-control policies in a form such that computers can enforce them. A second, high-level type of policy languages (e.g., the W3C Platform for Privacy Preferences, P3P) is inherently different from the first type, being primarily aimed at expressing access-control policies in a form that users can understand. As such, languages of the second type express privacy policies at a high level in generic user and data category terms, while those of the first type express privacy policies in terms of specific user identities or system-assigned user roles or other attributes, and in terms of specific data resource identities or system-assigned resource descriptors, hence in a fine-grained, internally applicable form. Clearly, the two types of policies serve complementary purposes.
A difficulty arising in connection with the low-level type of AC languages is how to apply it efficiently in order to control access to a database.
XACML is the subject of standardization work in a Technical Committee of the Organization for the Advancement of Structured Information Standards (see http://www.oasis-open.org). A policy encoded with XACML consists of functional expressions on the attribute values in the request and the return value of the policy is one of Permit, Deny, Not Applicable, or Indeterminate. An XACML policy can apply to many different situations, that is, different subjects, resources, actions and environments and may give different results for them. The XACML specification defines how such a request is evaluated against the policy, particularly what policy attributes are to be evaluated or, at least, which values are required to exist for a successful evaluation to result. Key characteristics of this evaluation process are that the request (the query against the policy) must describe the attempted access to a protected resource fully. In practice, it may be that the request is constructed in multiple stages by different components, so that a PEP (Policy Enforcement Point) provides only some initial attribute values and a PDP (Policy Decision Point) or other components can fetch more values from remote sources as they are needed. However, this does not change the situation that the policy cannot be evaluated unless all attribute values which describe the attempted access and are referenced by the policy are known, either directly, or through multi-stage lookup from one or more remote attribute sources.
The applicant has filed other patent applications within technology related to access control policies of the low-level type, in particular improvements to their implementation and management. For instance, the International Application published as WO 2010/128926 A1 discloses a method for controlling the distribution of policy data in a system. In one embodiment, a simplified policy is derived from a full policy by evaluating a partial access control request containing static attributes of a protected means. The resulting simplified policy is sent to a policy decision means, where it is used, as needed, for evaluating any further access control request relating to the protected means. By evaluating such further access control requests against a simplified policy, the computational load on the policy decision means is reduced.
U.S. Pat. No. 7,243,097 B1 belongs to the field of high-level policy languages, more precisely P3P. In a system described therein, a user query in a format adapted for submission to a database is transformed into an equivalent query that implements restrictions specifying access to data in the database. For this purpose, the system comprises a policy translator, which converts a policy in high-level, non-attribute-based language into restrictions that implement the policy. The transforming of the database query into an equivalent query relies on metadata stored in certain portions of the database, which must be accessed by the policy translator in order for it to complete the query transformation process. The user may access the database by means of the resulting equivalent query.